都会|事实_24年了，终于有人发现curl的这个Bug了

篇首语：本文由编程笔记#小编为大家整理，主要介绍了24 年了，终于有人发现 curl 的这个 Bug 了相关的知识，希望对你有一定的参考价值。

这是一个关于 COOKIE、互联网代码和 CVE&＃xff08;通用漏洞披露&＃xff09;的故事。

curl 作者 Daniel Stenberg 近日在个人博客分享了一个存在 23.9 年的 curl 漏洞。curl 是常用的命令行工具&＃xff0c;用来请求 Web 服务器&＃xff0c;于 1997 年首次发行。

据 Stenberg 透露&＃xff0c;这个漏洞是在 curl 发布后的第 201 天引入的&＃xff0c;但是直到第 8930 天&＃xff0c;漏洞才修复好。一个持续了 23.9 年的漏洞背后有着怎样的故事&＃xff1f;

一切还得从 1998 年说起。

curl 4.9 与 COOKIE

1998 年 10 月&＃xff0c;Stenberg 带领团队推出了 curl 4.9 版本。当时&＃xff0c;听过或用过 curl 的人还少得可怜。几个月之后&＃xff0c;curl 官网才宣布新版本的下载量达到了 300。那时&＃xff0c;无论从何种意义上讲&＃xff0c; curl 都还很小众。

curl 4.9 作为第一个带有 “COOKIE 引擎” 的版本&＃xff0c;可以接收 HTTP COOKIE、解析、识别&＃xff0c;并在后续的请求中把 COOKIE 正确地返回。在 curl 中&＃xff0c;处理 COOKIE 的大部分代码都是 Stenberg 编写的。

那会&＃xff0c;COOKIE  还没有明确的规范&＃xff0c;仅有的一份描述 COOKIE 工作原理的规范&＃xff0c;是一份由 Netscape 管理的文档 COOKIE_spec&＃xff08;感兴趣的同学可以戳链接查看文档副本&＃xff1a;https://curl.se/rfc/COOKIE_spec.html&＃xff09;。这份文档并不完善&＃xff0c;有不少信息需要通过查看其它客户端才能了解到。

Stenberg 在实现处理 COOKIE 的代码时&＃xff0c;就是参考了这份文档以及当时浏览器的大致处理方式。

此后十年&＃xff0c;IETF&＃xff08;互联网工程任务组&＃xff09;一直在努力创建 COOKIE 规范&＃xff0c;但均以失败而告终。这些早期 COOKIE 规范的创建者可能觉得&＃xff0c;他们创建了标准&＃xff0c;世界就会情不自禁地遵守它们&＃xff0c;但事实并非如此。COOKIE 的特殊之处在于&＃xff0c;有很多不同的作者、代码库和网站实现了它。因此&＃xff0c;很难从根本上改变它们的工作方式。

直到 2011 年&＃xff0c;COOKIE RFC 正式发布了&＃xff0c;它记录并解释了 COOKIE 实际的使用方式&＃xff0c;这可以说是真正意义上的 COOKIE 规范。Stenberg 本人也参与了规范的制定过程&＃xff0c;并在其中阐述了自己的观点和意见。对于这份规范的内容&＃xff0c;虽然 Stenberg 并不完全赞同&＃xff0c;但与此前的各种 COOKIE 规范相比&＃xff0c;COOKIE RFC 的确是一个巨大的进步。

COOKIE 双重语法带来的挑战

一开始&＃xff0c;新的 COOKIE 规范并没有给 Stenberg 造成困扰&＃xff0c;但很快&＃xff0c;规范的特殊编写方式让 Stenberg 倍感头疼&＃xff1a;它针对服务器如何发送 COOKIE 提供了一种字段语法&＃xff0c;而针对客户端应该接受什么样的 COOKIE 提供了另一种语法。也就是说&＃xff0c;同样的 COOKIE&＃xff0c;需要两种语法。

这有两个很直接的缺点&＃xff1a;

1. 规范很难阅读。你很容易就停留在其中一种语法上&＃xff0c;以为那就是适合自己用例的&＃xff0c;但却没有意识到角色描述是错误的。

2. 定义如何发送 COOKIE 的语法其实并不重要&＃xff0c;因为如何接收和处理 COOKIE 都是由客户端决定的。现有的大型 COOKIE 解析器&＃xff08;浏览器&＃xff09;有一定程度的自由决定自己接受什么&＃xff0c;所以没人注意&＃xff0c;也没人关心服务器是否严格遵守了规范中的语法。与此同时&＃xff0c;COOKIE 规范也在持续更新。从几年前开始&＃xff0c;IETF 就一直在修订和更新 2011 年的 COOKIE 规范&＃xff0c;计划将世界上一些已实际投入使用的 COOKIE 扩展添加到规范中。这项 COOKIE 规范更新工作被称为 6265bis。

curl 也同步进行更新&＃xff0c;以确保符合 RFC 6265bis 草案版本的规定。

但是&＃xff0c;双重语法仍然是 COOKIE 规范文档中悬而未决的问题。

随着时间的推移&＃xff0c;COOKIE 的发展变得缓慢。在过去的几十年里&＃xff0c;HTTP 规范也就更新了有限的几次&＃xff0c;但值得一提的是&＃xff0c;HTTP 服务器实现已经实施了更严格的解析策略&＃xff1a;

如果传入的 HTTP 请求看上去“非法”或格式不正确&＃xff0c;那么 HTTP 服务器就会提前拒绝&＃xff0c;把它们挡在门外。对于请求中的控制代码尤其如此。如果你试图将一个包含控制代码&＃xff08;这里的控制代码指的是介于 1 到 31 之间的字节值&＃xff0c;不包括 9&＃xff0c;9 是 TAB&＃xff09;的请求发送到一个相当新的 HTTP 服务器&＃xff0c;那么服务器很可能会拒绝&＃xff0c;并返回 400 响应代码。从 2016 年 12 月发布的 2.4.25 版本开始&＃xff0c;HTTP 服务器 Apache httpd 就默认启用了此行为。最新版本的 nginx 似乎也是这样做的。

如果是现在设计 COOKIE&＃xff0c;那么肯定会有所不同。

设置 COOKIE 的网站把 COOKIE 发送到客户端&＃xff0c;对于其发送的每个 COOKIE&＃xff0c;它都会设置多个属性。尤其是当需要客户端发回 COOKIE 时&＃xff0c;它会设置匹配参数。

在 COOKIE 的这些参数中&＃xff0c;其中有一个是 domain&＃xff0c;客户端发送 COOKIE 时要匹配它。服务器www.example.com可以设置 COOKIE 的有效范围为整个example.com域&＃xff0c;这时&＃xff0c;客户端在访问second.example.com 时也会发送 COOKIE。也就是说&＃xff0c;服务器可以将 COOKIE 设置为适用于“兄弟站点”。

值得一提的是&＃xff0c;1998 年添加到 curl 中的 COOKIE 代码在接受内容方面相当自由&＃xff0c;当然&＃xff0c;多年来也经过了不少调整和完善&＃xff0c;不过它始终与现实世界的网站保持了兼容。对于那部分代码&＃xff0c;Stenberg 修改的主要动力始终是为了使 curl 的 COOKIE 处理方式与其他已有的使用 COOKIE 的代理保持基本一致&＃xff0c;并可以互操作。

curl 的 Bug 详情与修复方案

2022 年 6 月底&＃xff0c;Stenberg 收到了一份报告&＃xff0c;报告怀疑 curl 中存在安全问题。正是这份报告促使 curl 发布了 CVE-2022-35252。

事实证明&＃xff0c;源于 1998 年的旧 COOKIE 代码&＃xff0c;会接受包含控制代码的 COOKIE。控制代码可以是名称或内容的一部分&＃xff0c;如果用户启用了“COOKIE 引擎”&＃xff0c;那么 curl 就会存储那些 COOKIE&＃xff0c;并在后续的请求中将它们发送回来。

例如&＃xff0c;curl 会接受下面这样的 COOKIE&＃xff1a;

Set-COOKIE: name^a&＃61;content^b; domain&＃61;.example.com

^a 和 ^b 表示控制代码。由于域可以将 COOKIE 标记为适用于其他主机&＃xff0c;、所以发送到域中所有主机的请求都会包含这个 COOKIE。

当 curl 将类似那样的一个 COOKIE 发送到 HTTP 服务器时&＃xff0c;它的外发请求中会包含下面这样一个 header 字段&＃xff1a;

COOKIE: name^a&＃61;content^b

对此&＃xff0c;Apache httpd 及其他服务器的默认配置都会返回 400。一个脚本或应用程序在收到这样的 COOKIE 后&＃xff0c;如果后续的请求中还继续发送 COOKIE&＃xff0c;就会遭到拒绝。

Stenberg 复盘后发现&＃xff0c;COOKIE 规范 RFC 6265 5.2 节确实说了&＃xff0c;客户端应该丢弃包含控制代码的 COOKIE&＃xff0c;但这部分对用户来说理解起来比较难&＃xff0c;需要对文档有深入的研究才能发现。此外&＃xff0c;规范并没有提及“控制代码”或是字节值范围。

Stenberg 认为&＃xff0c;要弄清楚主流浏览器是怎么做的还是比较容易的&＃xff0c;因为它们的源代码很容易获得。事实证明&＃xff0c;Chrome 和 Firefox 都已经忽略了包含以下任何字节的传入 COOKIE&＃xff1a;

%01-%08 / %0b-%0c / %0e-%1f / %7f

其中不包含 %09&＃xff08;TAB&＃xff09;和 %0a / %0d&＃xff08;行结束符&＃xff09;。

Bug 修复方面&＃xff0c;Stenberg 表示&＃xff0c;curl 的修复补丁处理方式非常简单&＃xff1a;拒绝包含一个或多个禁用字节值的 COOKIE 字段。Stenberg 认为&＃xff0c;这种修改基本是没有风险的。

写在最后

推算起来&＃xff0c;有漏洞的代码从 curl 4.9 版本开始就一直存在&＃xff0c;curl 7.85.0 版本才完成修复。整个历程有 8729 天&＃xff08;23.9 年&＃xff09;。也就是说&＃xff0c;这个 Bug 是在项目发布的第 201 天引入的&＃xff0c;到第 8930 天才修复。

Stenberg 认为&＃xff0c;代码在发布时是没什么问题的&＃xff0c;并且在用户的使用过程中&＃xff0c;也基本没有产生什么问题。它的问题出在&＃xff0c;HTTP 服务开始拒绝可能的恶意 HTTP 请求时。如此一来&＃xff0c;这段代码就变成了一种拒绝服务&＃xff0c;这或多或少会带来一些副作用。

或许&＃xff0c;这个 Bug 诞生于 RFC 6265 发布之时。或许&＃xff0c;它诞生于 HTTP 服务器开始拒绝这些请求时。不管怎样&＃xff0c;这个 Bug 创造了一个新的项目记录&＃xff1a;它是第四个被发现之前存在了 8000 多天的 Bug。